About HTTP Smuggling (CL.TE, TE.CL, TE.TE, CL.0, H2.CL …) and Smuggling example

1. Background ( Content-Length / Transfer-Encoding: chunked )1.1 Content-Length 1.2 Transfer-Encoding: chunked 1.3 취약점 등장 배경 2. HTTP Smuggling (HTTP 1.1)2.1 CL-TE 2.2 TE-CL 3.3 TE.TE 2.4 CL.0 3. HTTP Smuggling (HTTP/2)3.1 HTTP/1.1 vs 2 3.2 downgrades HTTP/2 requests 4. Smuggling 예시 4.1 /admin 경로 접근 방지 우회 4.2 미들웨어→엔드서버 정보 유출 / 사용자 요청 Leak Reference

1. Background ( Content-Length / Transfer-Encoding: chunked )

1.1 Content-Length

개념

Content-Length 헤더는 HTTP 응답 또는 요청의 본문 길이를 바이트 단위로 나타냅니다. 클라이언트와 서버는 이 값을 통해 데이터를 전송할 때 어디까지 읽어야 하는지 알 수 있습니다.

보통 전송할 데이터의 전체 크기를 미리 알고 있을 때 사용됩니다. 헤더에 이 값이 포함되면, 클라이언트는 본문 데이터를 정확히 그 길이만큼 읽습니다.

사용

정적 콘텐츠 전송: HTML 파일, 이미지, 비디오 등의 정적 파일을 전송할 때 주로 사용됩니다. 이러한 파일의 크기는 전송 전에 미리 알 수 있으므로 Content-Length를 사용해 파일 크기를 명시할 수 있습니다.

단일 요청/응답 데이터: 요청이나 응답의 데이터 크기가 고정적이고 미리 알 수 있는 경우에 사용됩니다. 예를 들어, 정적 웹 페이지를 제공하는 경우에 적합합니다.

예시

예를 들어 abcdef 라는 문자열을 보낼때에는 byte가 6이기 때문에 다음과 같이 전송됩니다.


POST /somewhere HTTP/1.1
Content-Type: ~
Content-Length: 6

abcdef

1.2 Transfer-Encoding: chunked

개념

Transfer-Encoding: chunked는 HTTP/1.1에서 도입된 메커니즘으로, 데이터가 일정한 크기의 청크(chunk)로 나뉘어 전송됩니다. 각 청크는 자체적으로 크기를 가지고 있으며, 클라이언트는 각 청크의 길이를 읽은 다음 해당 청크 데이터를 읽습니다.

chunked 전송 인코딩은 데이터의 총 크기를 미리 알 수 없는 경우에 유용합니다. 각 청크의 끝은 0 크기의 청크로 표시되어 데이터의 끝을 알립니다.

사용 상황

동적 콘텐츠 전송: 데이터의 크기를 미리 알 수 없는 경우, 예를 들어, 실시간으로 생성되는 데이터나 스트리밍 콘텐츠를 전송할 때 사용됩니다.

데이터 생성 시간이 긴 경우: 서버가 데이터 생성에 시간이 걸리는 경우에도 유용합니다. 예를 들어, 대형 보고서 생성과 같은 작업이 끝날 때까지 기다리지 않고, 부분적으로 생성된 데이터를 바로 전송할 수 있습니다.

예시


POST /somewhere HTTP/1.1
Content-Type: ~
Transfer-Encoding: chunked

6\r\n
abcdef\r\n
0\r\n
\r\n

여기서 중요한 점은 데이터 전송 종료 부분에서 0\r\n\r\n을 보낸다는 것 입니다.

1.3 취약점 등장 배경

최근에는 프론트/백엔드 서버로 나누어서 환경을 구축하거나, 대용량 트래픽을 처리하는 경우 로드 밸런싱을 통해 트래픽을 분산하는 등 다양한 서버 구축 환경이 존재합니다. 이때 트래픽을 처리하는 과정에서

미들웨어와 엔드서버의 데이터 전송을 받아들이는 방식이 다르면 Smuggling 취약점이 발생합니다.

💡

시작하기 전

해당 글을 시작하기 전에 용어가 헷갈릴 수 있어 정리하겠습니다.

미들웨어 == 리버스 프록시, 프론트엔드 서버 등등 중간지점

엔드서버 == 백엔드 서버

2. HTTP Smuggling (HTTP 1.1)

HTTP Smuggling에서 Smuggling은 밀수 라는 뜻을 가지고 있습니다. 미들웨어와 엔드서버에서 데이터 전송 방식을 다르게 받아들일 경우 발생하는 취약점 으로 다음과 같은 형식으로 표현합니다. 결과적으로 엔드서버 소켓에서 밀수 된 데이터가 남아 두 번째 패킷과 결합하여 발생하는 취약점 입니다.

Smuggling 유형

여기서 CL은 Content-Length이고 TE는 Transfer-Encoding 입니다. CL과 TE의 순서가 중요하며, 해당 유형을 기초로 하여 다양한 방법을 통한 Smuggling을 할 수 있습니다.

CL-CL

CL-TE

TE-CL

TE-TE

CL.0

CL-CL은 보통 400 상태 코드를 응답함으로, 해당 공격을 제외하고 서술하겠습니다. ( 읽다 보면 CL-CL도 자연스럽게 알게 되십니다. )

2.1 CL-TE

미들웨어가 CL(Content-Length)을, 엔드서버가 TE(Transfer-Encoding) 헤더 형식으로 데이터 전송을 지원할 때 취약점이 발생합니다.

예시로 어떤 사이트에 CL-TE 공격을 수행해 보겠습니다. Content-Length를 지원하는 미들웨어에 Content-Length와 Transfer-Encoding헤더를 둘 다 작성합니다.

프론트엔드는 CL을 지원하기 때문에 POST데이터 길이인 35만큼 데이터를 받아들입니다.

하지만 Transfer-Encoding을 지원하는 엔드 서버는 어떨까요?

다음과 같이 두 서버가 한개의 요청에 다른 해석을 수행합니다. CL은 미들웨어(리버스 프록시, 혹은 제 1서버)가 해석할 범위이고, TE는 엔드서버(백엔드 서버)가 해석할 범위입니다.

엔드서버는 0\r\n\r\n을 마지막으로 패킷이 종료되었다고 판단합니다.

이렇게 되면 0\r\n\r\n 이후의 데이터는 종료되지 않은 엔드서버의 소켓에 데이터로 남게 됩니다.

🔎 첫 번째 요청 도식화

클라이언트(공격자)는 Smuggling 페이로드가 담긴 패킷을 미들웨어에 전달합니다.

리버스 프록시는 패킷에 이상이 없기 때문에 백엔드 서버로 전달합니다.

서버는 Transfer-Encoding 헤더 형식에 따라 0\r\n\r\n 까지만 패킷을 받아 처리합니다.

처리되지 않은 smuggling 페이로드는 엔드 서버 소켓에 남아있게 됩니다.

그럼 두 번째 요청에는 어떤 응답이 담겨올까요?

두 번째 패킷입니다.

smuggling 공격이 성공하여 404 Error을 반환합니다.

🔎 두 번째 요청 도식화

클라이언트(공격자)의 요청 패킷이 미들웨어를 거쳐 백엔드 서버까지 도달합니다.

백엔드 서버에서는 처리되지 못한 smuggling 페이로드 + 두 번째 요청 패킷이 결합되고, 서버에서는 결합된 패킷을 처리하여 응답합니다.

결합된 패킷은 서버가 해석하기에 /404 경로로 요청하는 것에 대한 응답을 수행합니다. (없는 웹사이트에 요청하기 때문에 Not Found 데이터가 응답됩니다.)

💡

그럼 어떤 영향을 끼칠 수 있을까요?

공격자가 요청을 두 번 수행하여 접근할 수 없는 경로로 접근하거나

공격 이후 요청된 클라이언트의 요청을 오염 시킬 수 있습니다.

2.2 TE-CL

엔드서버가 CL(Content-Length)을, 미들웨어가 TE(Transfer-Encoding) 헤더 형식으로 데이터 전송을 지원할 때 취약점이 발생합니다.

예시로 어떤 사이트에 TE-CL 공격을 수행해 보겠습니다.

0 이전까지의 길이를 측정합니다. (5e)

버프를 쓰는 경우 0 이전까지의 데이터를 드래그로 긁으면 옆에 hex값이 나타납니다.

5e는 길이의 hex값 입니다.

다음과 같이 두 서버가 한개의 요청에 다른 해석을 수행합니다. TE는 미들웨어(리버스 프록시, 혹은 제 1서버)가 해석할 범위이고, CL는 엔드서버(백엔드 서버)가 해석할 범위입니다.

처음 프록시(TE)는 0\r\n\r\n 이전까지의 데이터를 전부 body값으로 보고 백앤드 서버(CL)로 넘기게 됩니다.

CL은 Content-Length가 4 임으로, 5e를 제외한 데이터는 읽지 않습니다.

이렇게 남은 데이터는 서버의 소켓에 잔여 데이터로 남게 됩니다.

💡

왜 Content-Length가 4로 측정되나요? → (바이트)

\r

\n

🔎 첫 번째 요청 도식화

클라이언트(공격자)는 미들웨어(프록시)에게 Smuggling 페이로드가 담긴 POST 요청을 보냅니다.

미들웨어는 TE로 판단하고 정상 패킷으로 간주, 백엔드 서버로 전송합니다.

백엔드 서버는 CL로 판단하고 TE 형식에서 데이터의 길이를 나타내는 5E까지만 Body로 판단합니다.

이렇게 5E 뒤에 있는 Smuggling 패킷은 잔여 데이터로 소켓에 남아있게 됩니다.

두 번째 패킷입니다.

CL-TE와 마찬가지로, 소켓에 남아있던 데이터와 두 번째 패킷이 합쳐져 /404페이지로 요청한 것에 대한 응답이 오게 됩니다.

🔎 두 번째 요청 도식화

클라이언트가 두 번째 패킷 전송

미들웨어 → 엔드 서버 패킷 전송

엔드서버 소켓에 남아있던 잔여 데이터 + 두번째 패킷이 결합해서 공격자가 의도한 요청 생성(/404)

서버는 클라이언트에게 /404 경로로 요청한 것에 대한 응답을 반환됩니다.

3.3 TE.TE

같은 Body 처리 방식(Transfer-Encoding)을 사용해도 취약점이 발생하기도 합니다. Transfer-Encoding 헤더를 다양한 방식으로 난독화 혹은 조작하여, 미들웨어 혹은 엔드서버 둘중 하나가 처리를 하지 않게 하면됩니다.

🔎 예시로 다음과 같은 패킷을 전달해 보겠습니다.


POST / HTTP/1.1
Content-Type: application/x-url-form-encoded
Content-Length: 4
Transfer-Encoding: chunked
Transfer-Encoding: wtf

5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15

x=1
0

프론트엔드 서버는 Transfer-Encoding: wtf를 보고 올바르지 않다고 생각하여 Content-Length으로 해당 Body 데이터를 파싱합니다. 이렇게 되면 CL.TE 취약점이 발생하게 됩니다.

다른 점은, 미들웨어와 엔드서버가 CL과 TE를 모두 파싱 하지만, 프론트엔드에서는 Transfer-Encoding: wtf를 이상하다고 판단하여 Content-Length 로 파싱한 것 입니다.

Content-Length를 정상적으로 주었을 때는 문제 없이 동작합니다.

이런 식으로 TE를 난독화하여 서버 중 하나가 헤더를 처리하지 않도록 할 수 있습니다. 두 개의 서버 중 한 개의 서버만 TE 헤더를 처리하지 않게 되면 나머지 과정은 기존의 CL.TE, TE.CL 취약점과 같습니다.

🤪 난독화 종류


Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

2.4 CL.0

CL.0은 미들웨어에서는 CL을 처리하지만 엔드서버에서는 CL을 처리하지 않을 경우 발생하는 취약점 입니다.

동일 TCP Connection에서 발생하기 때문에 헤더에 Connection: keep-alive가 있어야 합니다. (혹은 버프 설정을 만지다 보면 자동으로 요청 시 붙여주는 것 같기도 합니다.)

예시로 미들웨어 에서는 Content-Length: 30을 해석하기 때문에 문제 없이 작동합니다.

하지만 해당 요청은 엔드서버에서 Content-Length가 파싱되지 않습니다. (그래서 CL.0) 이라고 합니다.

(해당 문제에서는 백엔드서버가 /resources 경로는 자원을 표시하기에, Body 데이터를 파싱하지 않아 발생한다고 생각됩니다.)

이렇게 무시된 두 번째 패킷은 다음번 요청에 Smuggling 됩니다.

두 번째 일반 패킷입니다. 예상대로 /경로에 요청을 하였지만 Smuggling된 패킷의 요청으로 이동합니다.

3. HTTP Smuggling (HTTP/2)

3.1 HTTP/1.1 vs 2

Smuggling을 하는 관점에서 HTTP 버전은 중요한 차이를 보입니다.

예시로 HTTP/1.1에서 헤더 전송 방식은 텍스트 기반으로 전송되며, \r\n으로 구분됩니다. 하지만 HTTP2는 바이너리 프레임으로 전송되기 때문에 개행을 사용할 필요도 없고, 프레임 단위로 전송되기 때문에 Content-Length또한 사용되지 않습니다.

표현 방식 또한 다릅니다. 예시로 같은 웹 요청 패킷을 버전에 따라 다르게 표현하면 다음과 같습니다.

🔎 HTTP/1.1


GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.8
Accept-Encoding: gzip, deflate, sdch
Connection: keep-alive

🔎 HTTP/2


:method: GET
:scheme: https
:authority: www.example.com
:path: /index.html
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-language: en-US,en;q=0.8
accept-encoding: gzip, deflate, br

실제로 콜론으로 표현되진 않으며, 바이너리 데이터로 인코딩되어 전송됩니다.

3.2 downgrades HTTP/2 requests

HTTP/2 환경에서는 기존에 존재하는 Smuggling공격을 사용할 수 없습니다.

대신 클라이언트와 미들웨어가 http/2 통신을 수행하고, 미들웨어와 엔드서버가 HTTP/1.1 통신을 수행한다면

, 취약점을 트리거 할 수 있습니다.

H2.CL

➡️ 프론트엔드 → 미들웨어 : HTTP/2 사용

➡️ 미들웨어 → 엔드서버 : HTTP/1.1 사용


POST / HTTP/2
Host: front
~
Content-Length: 0 #핵심

엔드서버에서는 Content-Length가 0이라고 생각함으로써 이후에 오는 패킷은 소켓에 데이터가 남게 됩니다.

두 번째 요청부터는 피해자의 요청이 Smuggling된 패킷 뒤로 붙어 공격이 실행됩니다.

🎯 예시

H2.TE

HE.CL과 동일한 방식입니다.


POST / HTTP/2
Host: YOUR-LAB-ID.web-security-academy.net
Transfer-Encoding: chunked

0

GET /admin HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net

HTTP/2에서는 Transfer-Encoding을 처리하지 않음으로, 해당 패킷이 그대로 엔드 서버로 넘어가게 되고 이때 엔드 서버가 TE를 처리하며 Smuggling이 발생하게 됩니다.

4. Smuggling 예시

4.1 `/admin` 경로 접근 방지 우회

보통 /admin 경로는 localhost와 같은 내부망에서만 접근할 수 있도록 하거나, IP 화이트리스트 운용 등을 통해 접근을 통제합니다.

예시로 해당 사이트에서 /admin경로로 접근하려고 하면 block 당하는 것을 볼 수 있습니다.

CL-TE 취약점이 있는 것을 파악하고, Smuggling 공격을 통해 /admin 경로에 접근합니다.

local users만 패널이 허용되어 있다고 나옵니다.

여기서 얻을 수 있는 정보는 프론트엔드에서 제어하던 인가 정책을 우회 했다는 것 입니다.

local users가 내부 망에 속한 유저들을 지칭할 확률이 높기 때문에, Host헤더를 추가해서 확인해 보겠습니다.

헤더가 중복되었다고 뜹니다.

아마도 이후에 요청되는 패킷과 합쳐질 때, 헤더가 중첩되어 그런 것 같습니다.

이후에 오는 데이터를 Body처리를 하여 변경해 보겠습니다.

HTTP/1.1 표준은 GET 요청에 Body를 포함하는 것을 금지하지는 않지만, 대부분의 웹 서버와 클라이언트는 GET 요청의 Body를 무시하도록 구현되어 있습니다. 때문에, 이후에 오는 패킷을 Body값에 보내게 되면 일반적인 GET 요청과 같다고 할 수 있습니다.

여기서 두 번째로 등장하는 Content-Length는 임의로 부여합니다.

이후에 오는 데이터가 Body 데이터로 들어가고, Body 데이터로 들어간 헤더 정보는 무시됨으로, 정상적으로 admin panel에 접근할 수 있게 됩니다.

4.2 미들웨어→엔드서버 정보 유출 / 사용자 요청 Leak

미들웨어 → 엔드 서버 내용 캡쳐

여기에 웹사이트에 흔하게 사용되는 검색 기능이 존재합니다.

웹사이트는 검색한 내용을 Response 페이지에 검색 결과와 함께 보여줍니다.

이러한 경우 CL-TE취약점을 이용하게 되면, 미들웨어가 엔드 서버에 요청하는 정보를 캡쳐할 수 있습니다.

💡

어떤식으로 가능할까요?

그림과 같이, 첫 번째 Smuggling 패킷에서 Content-Length를 충분하게 길게 주고 search 파라미터 뒤에 value를 비워둡니다.

이렇게 되면 엔드 서버의 소켓에 Smuggling된 페이로드가 남게 됩니다.

이때 두 번째 요청을 발생시키면 search=두번째 요청 형태로 미들웨어가 엔드 서버로 보낸 요청이 검색 기록처럼 Store 되기 때문에 공개되지 않은 헤더 정보 유출이 가능합니다.

보통 미들웨어에서 추가된 헤더를 엔드서버에서 파싱하고 노출하지 않기 때문에 알아낼 방법이 없습니다.

하지만 HTTP Smuggling을 통해 요청 패킷 자체를 Leak 함으로써, 비밀 헤더를 알아낼 수 있었습니다.

사용자 요청 Leak

마찬가지로 HTTP Smuggling을 사용하면 일반 유저의 쿠키정보, 특정 헤더, 인증 정보등을 앞서 설명한 방식처럼 해킹할 수 있습니다.

사용자의 요청이 웹사이트에 저장되는 서비스를 찾습니다.

HTTP Smuggling 을 통해 웹사이트에 무언가가 저장되는 패킷을 Smuggling 합니다.

사용자가 웹사이트에 접근합니다.

Smuggling된 패킷과 사용자의 접근 패킷이 합쳐짐으로써, 사용자는 자신의 요청 정보를 웹사이트에 저장하게 됩니다.

공격자는 저장된 정보를 바탕으로 사용자인 척 위장 합니다.

🔎 예시

⚠️ 예시 입니다. 패킷 정보가 올바르지 않을 수 있습니다.

공격자는 Smuggling 패킷의 Content-Length를 충분히 주고, email= 을 통해 사용자의 정보가 이메일 섹션에 담기게 합니다.


POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: <CL-TE>
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=your-session-token

name=attacker&email= #사용자의 정보가 이후로 담김




# 스머글링 데이터 + 두번째 패킷
POST /post/comment HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 400
Cookie: session=your-session-token

name=attacker&email=  #두번째 패킷의 시작(피해자)
GET / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Cookie: session=피해자 토큰

공격자의 Smuggling 시도 이후, 웹 서버에 접근한 피해자는 자신의 요청 정보를 /post/comment에 저장하게 됩니다.

이런 식으로 Smuggling은 다양한 취약점을 내포하고 있습니다. 서버의 데이터 파싱 방법에 따라 분석하고, 어떤 정보를 유출할 수 있는지 확인하여야 합니다.

Reference

What is HTTP request smuggling? Tutorial & Examples | Web Security Academy

In this section, we'll explain HTTP request smuggling attacks and describe how common request smuggling vulnerabilities can arise. Labs If you're already ...

https://portswigger.net/web-security/request-smuggling#what-is-http-request-smuggling

HTTP/2 소개 | Articles | web.dev

HTTP/2 (또는 h2)는 웹에 푸시, 다중화 스트림 및 프레임 제어를 제공하는 바이너리 프로토콜입니다.

https://web.dev/articles/performance-http2?hl=ko